Resource reservation protocol-traffic engineering (RSVP-TE) is a transport layer protocol standard used in many network systems to allow individual applications to receive different qualities of service (QoS) for respective data flows. For example, certain multimedia applications (e.g., Voice over IP, videoconferencing, etc.) may require a regular and continuous delivery of data. Such applications place a greater emphasis on the timeliness of the data delivery, and less emphasis on the reliability of such data delivery. On the other hand, more traditional applications (e.g., downloadable content) typically require reliable data delivery, with less regard as to when or how often each data packet is delivered.
In the past, data paths in a network were typically configured and torn down manually. For example, a user would specify which nodes in the network were to form the data path, and then manually allocate resources within each node (e.g., according to QoS requirements). Furthermore, at the end of a data session, the user would then perform a manual reallocation of the resources (i.e., “tear down” the data path). However, RSVP-TE works by dynamically “reserving” and maintaining appropriate resources (e.g., according to application-specific QoS requirements) in each node along a data transmission path. RSVP-TE automatically establishes a data path across one or more nodes in a network by enabling each individual node to communicate control information to one or more adjacent nodes.
FIG. 1 illustrates a typical initialization of an RSVP-TE session within a network 100. The network 100 includes two host devices 110 and 140, as well as two routers 120 and 130. Suppose, in this example, host 110 wishes to establish a data session with host 140. Host 110 first sends a “path” request (PATH) to an adjacent node (router 120), using the internet protocol (IP) address of destination node (host 140) for routing purposes. For example, a routing protocol within host 110 may utilize a routing table (or look-up table) to determine which adjacent node to forward the PATH request to, based on the destination IP address. The PATH request includes information necessary to establish a data session between host 110 and host 140, including: the IP address of the previous node in the data path, the format of data packets to be sent, traffic characteristics of the data flow, and advertising information. Upon reception, router 120 stores a “path state,” based on the PATH request, and then forwards the PATH request to the next node in the data path (router 130), based on the destination IP address. The stored path state will be used to trace the data path backwards, hop-by-hop, from host 140 to host 110, as is discussed in further detail below. Upon reception, router 130 also stores a path state and forwards the PATH request to the destination node (host 140), based on the destination IP address.
Once the PATH request is received by host 140, it too stores a path state based on the PATH request. Host 140 then reserves the appropriate resources needed to maintain the particular QoS, based on the request parameters. Host 140 then sends a “reservation” request (RESV) to the previous node in the data path (router 130), based on the stored path state. The RESV request identifies the resources to be reserved within each node, based on the particular QoS parameters. Router 130 then reserves the requested resources, in response to the RESV request from the host 140, and sends a RESV request to the previous node in the data path (router 120), based on the stored path state. Accordingly, router 120 reserves the requested resources, in response to the RESV request from router 130, and sends a RESV request to the source node (host 110), based on the stored path state. Finally, reception of the RESV request by host 110 indicates the establishment of a data session between host 110 and host 140. Host 110 may thus begin transmitting data packets to host 140.
In addition to the PATH and RESV requests described above, other forms of RSVP-TE messages may include, but are not limited to: PATH error, indicating an error encountered during the processing of a PATH request; RESV error, indicating an error encountered during the process of a RESV request; PATH tear, indicating a tear-down of a PATH session; RESV tear, indicating a tear-down of a RESV session; CONFIRM, confirming the success of a PATH request; and HELLO, initiating a RSVP-TE connection with a neighboring node.
Due to the dynamic nature in which RSVP-TE creates and maintains data paths, each node along the data path is established in a “soft state.” Thus, each node is responsible for periodically “refreshing” its session status to neighboring nodes along the data path, as well as tearing down the session when a failure occurs. For example, refreshing may be accomplished by having each host or router along the data path periodically send a PATH or RESV request to its neighbors. In the event that a refresh is not received from a particular node, within an allotted amount of time (e.g., the “cleanup timeout” interval), it is assumed that a failure occurred within that node and the data session is subsequently torn down. Constantly tearing down and reconstructing data sessions is very inefficient, as the transfer of all data packets for the specific application cease for a period of time while a new data session is initialized (as in the example of FIG. 1). Thus, it is desirable to maintain a particular data session (once established) for as long as possible, by ensuring that each node sends out a refresh request before the cleanup timeout interval expires.
FIG. 2 illustrates a standard network interface device 200 which may be used in a router having RSVP-TE functionality. The network interface device 200 includes an active interface card 210, a standby interface card 220, a shared memory 250, and two data buses 212 and 222. Both the active interface card 210 and the standby interface card 220 are coupled to send and receive RSVP-TE (e.g., PATH and RESV) requests from adjacent nodes along a data path. However, the standby card 220 is prevented from interfacing directly with the network as long as the active card 210 is functioning normally. The shared memory 250 is coupled to both the active card 210 and the standby card 220 via data buses 212 and 222, respectively, and is used for storing dynamic session information. For example, each time the active card 210 receives a PATH request from a previous node, it updates a path state stored in the shared memory 250 based on the PATH request. Similarly, the active card 210 updates one or more resource reservation parameters stored in the shared memory 250 each time a RESV request is received. Because the standby card 220 has access to the dynamic session information stored in the shared memory 250, it is able to immediately assume the role of the active card 210 in the event of a failure (e.g., the active card 210 is unable to send refresh requests to adjacent nodes). Thus, by switching to the “redundant” standby card 220, a data session need not be torn down and reconstructed in the event of a failure within the active card 210. This technique, known as “hot redundancy,” allows data sessions to be maintained for extended periods of time.
One limitation of the network interface device 200 is that it requires a high level of hardware overhead. For example, the shared memory 250 is typically a dual port memory to allow access by both the active card 210 and the standby card 220. The communication links 212 and 222 are typically bi-directional data buses, to allow each of the active card 210 and the standby card 220 to store and retrieve data from the shared memory 250. A further limitation of the network interface device 200 is that the active card 210 and the standby card 220 are not allowed to access the shared memory 250 simultaneously, as doing so would significantly degrade the overall performance of the device 200. Thus, the standby card 220 is only allowed access to the shared memory 250 in the event of a failure in the active card 210. The standby card 220 then quickly processes the dynamic session information stored in the shared memory 250, in order to maintain the data session soft state for the current node, before the cleanup timeout interval expires. It is therefore desirable to achieve a network interface device with increased hot redundancy performance, while minimizing overall hardware overhead.